by Eric Goldman
This article describes some of the issues at play in structuring and negotiating Web development and hosting agreements.
As a threshold issue, we must define our terms. Web
development and hosting relationships encompass a broad range of substantive
relationships, and it is crucial that the substantive relationships be kept
separate to ensure proper analysis.
Development can encompass a broad range of activities. Although rarely does a customer obtain only one of these services, the services can be broadly segregated into the following categories:
(a) File Conversion. The most basic service, this involves file manipulation such as converting non-HTML documents into HTML and scanning photos or graphics and saving such files into GIF or JPEG.
(b) Web Design. This involves designing the look and feel of the website, including logos and banners, navigation bars or tools, page layout and object placement.
(c) Code Development. This involves coding HTML pages (from
scratch), cgi scripts, Java applets or other applications.
(d) System Integration-Website Only. This involves integrating
the website with one or more third party applications, such as chat engines,
search engines, electronic commerce store fronts, and so on.
Integration-Website and Back End Systems. This involves integrating the
website with one or more existing customer applications, such as legacy
The generic description "web hosting" can encompass a number of different relationships, such as:
(a) Collocation. Collocation occurs when the customer locates
customer-owned servers at the provider's facility. The provider is
"merely" responsible for connecting the servers to the Internet and
(usually) ensuring that the servers are up. In a straight collocation
relationship, the provider will not manipulate content on the servers. Providers
of these services usually provide space for the servers in chain-fenced
"cages." Collocators often offer additional services, such as
reselling equipment or software.
(b) Hosting. In a typical hosting relationship, the
provider (as opposed to the customer) provides the servers and software in
addition to the Internet connection. In some arrangements, the customer is
solely responsible for managing the content; in others, the provider may handle
some or all of the updates.
(c) Co-Branding. A popular technique has been to expand the
scope of a customer's website by co-branding pages on a third party's servers.
It is analytically appropriate to treat these co-branded pages as being hosted
by the third party.
(d) Outsourcing. Increasingly popular, outsourcing occurs
when a customer outsources one or more functions of its website to a third
party provider. By way of example, WhoWhere? allows a customer website to offer
co-branded email to its users by directing customer's users to co-branded pages
operated on WhoWhere?'s servers using WhoWhere?'s software. While outsourcing
is similar to co-branding, because the outsourcer is operating software for the
customer's (or its users') benefit, the customer is now also dependent on the
provider for the operation of this software.
Although not literally part of development or hosting, parties engaged in these businesses often offer additional services such as:
(a) Domain Name Registration. The provider will register
the customer's domain name with Internic (or others).
(b) Search Engine Registration. The provider will often
register the website URLs with the search engines to ensure that the pages are
indexed by the search engines.
(c) Online Promotion. The provider may engage in
promotional activities to promote the website or build the customer's online
image. This may include consulting on public relations on the Web, or perhaps
advising about integrating Internet promotions with
From the customer's perspective, website development is no
different from other types of development. Therefore, customers usually start
with their standard form of independent contractor agreement, of which most or
Within the parameters of a customer-favorable standard independent contractor agreement, ownership tends to be the stickiest point. Customer's usual starting point-that all development is a work-for-hire or otherwise owned exclusively by customer-tends to be unreasonable in light of the actual manner in which most web developers operate. Like other software developers, web developers tend to recycle components and utilities from project to project. Furthermore, for maintenance convenience, web developers find it beneficial to have all of their clients use a uniform set of tools. Therefore, web developers aggressively resist assigning ownership over certain aspects of their development efforts to one particular customer, because this would prevent the developer from recycling and standardizing.
Because the Web is constantly and quickly moving, customers often will want to spell out a rigorous development schedule coupled with effective remedies for failure to meet contracted milestones.
The customer must make a few platform decisions prior to development commencement. First, the customer must decide what platform the website will reside on (i.e., Unix v. Windows). Second, the customer must decide if the website will be optimized for a particular browser or will offer features that cannot be accessed by certain browsers. If the customer decides to do so, the customer will want to set up meaningfully rigorous acceptance tests to confirm that the desired browsers can access the developed functionality.
Pricing and Updates
As with other development agreements, the developer wants to be paid early, such as on a per-hour basis paid monthly or on a retainer basis. However, the customer will want to defer as much payment as possible until after acceptance. Unlike other development agreements, however, a website is never "finished." Although there may be an initial "go live" date, websites are living animals and will be constantly updated. Therefore, customer will want to specify clearly what it is buying and how the process of updating will be handled (and paid for). In particular, although there usually will be interim updates to the website, it is typical for websites to be completely overhauled, with respect to both look and feel and organization, periodically (i.e., once a year or every 6 months). Therefore, the parties should plan the development process and pricing for these redesigns-and what triggers a payment to developer and what does not.
Conclusion about Web Development
As is typically the case, the customer usually has lots to say in a Web development agreement, whereas usually the developer is happy to be silent on many of these points. As a result, state of the art developer-favorable agreements tend to be short-unacceptably short, from the customer's perspective.
From the customer's perspective, the most crucial set of provisions relate to the levels of service being provided. Unlike pure Internet service provision agreements, where providers are grudgingly making some promises about service availability (i.e., the service will be available 99% of the time, and if there are excess outages, the customer will receive discounts or credits), the state-of-the-art hosting provider-oriented agreements usually offer no such service promises.
Usually this is unacceptable to customers. There are a large number of substantive standards that the customers would like to see met:
(a) Server Response and Time and Throughput Capacity. Slow
servers and inadequate throughput capacity of the Internet connection each mean
long waits for users, which results in frustrated users.
(b) Server Uptime. Server outages mean that the website is
completely offline. Therefore, customers want to see this minimized.
(c) System Redundancy. To reduce the possible effect of
server problems or force majeure (such as an outage by an upstream ISP), some
customers choose to require the provider to mirror servers or to connect
customer's servers via multiple ISPs.
(d) User Support. User support can be a tricky issue, because
a user inquiry could be technical (i.e., the following URL did not load
properly or my password does not work) or substantive (i.e., does the
cardigan sweater come in taupe?). Therefore, a process needs to be developed to
allocate responsibility for user inquiries. Furthermore, customer will want
standards for how provider deals with user inquiries that are provider's
responsibility, including professionalism in communicating, timeliness of
response and escalation procedures for user inquiries that provider cannot
(e) Security. Depending on the system configuration and the
allocation of responsibilities between provider and customer, provider may not
have sole control over the security of the website. However, to the extent that
provider can control over security matters, customers will expect their
provider to do so. Usually this means proactively preventing security breaches
and laying out a process for fixing known security breaches once identified. At
minimum, customers usually expect providers to notify them when security
breaches or security holes are identified.
(f) Software Errors. To the extent that the host is also
responsible for site development, the customer will want standards regarding
how quickly provider must correct software or programming errors.
Rights in User Data
As Web-based business models become more refined, more customers are realizing that data collected from or about its users are an increasingly valuable asset. Therefore, customers need to take a number of steps to preserve and maximize the value of this asset. Since provider's servers are collecting information from or about users, customer's first step is to obtain copies of the server logs applicable to its website. Most providers now provide raw unprocessed server logs at no additional cost, but reports derived from the server logs may have a separate price tag. In any event, it is crucial for customers to get this data so they can learn more about their users.
Second, customer needs to treat all information about its
users as a trade secret. Not only is this crucial to restrict provider's
behavior, but it is also crucial to preserve a possible misappropriation suit
if some third party misappropriates user data (since if customer has not
protected the confidentiality of this information in all circumstances, it
cannot claim that such data is a trade secret).
If asked, collocators and hosts usually will designate
customer's user information as customer's trade secret, but co-branding or
outsource providers will often be less accommodating. Because user data has
such great potential value, trade secret license/"sharing" clauses
are becoming exponentially more complex and lengthy.
For customer, however, restricting any provider's use of
user data may be a bet-the-business proposition. If customer loses control of
this data, usually this will have ripple effects on customer's
business-potentially leaving customer's users exposed to spam or junk mail,
providing customer's competitors with a targeted list of potential customers
for its own goods or services, and educating customer's competitors and
customers (such as advertisers) about the true inner workings of customer's
Provider's Post-Termination Duties
State-of-the-art provider-favorable agreements usually are silent about what happens to the website after termination. However, from customer's perspective, this may be another bet-the-business provision. If the website's post-termination transition to a new provider is not handled properly, the website will likely be off-line or error-prone for a period of time-frustrating users and causing a loss of business.
Therefore, the customer wants to minimize the number of
circumstances by which the provider can unilaterally shut down the website or
otherwise stop performing under the agreement. Furthermore, the customer will
want to lay out a procedure, with time periods and effective remedies for
failure to meet the timeframes, for provider to transition the website to a new
provider and cooperate in all aspects of such transition. Ideally, customer
will have such transition procedures apply even if the customer is in breach of
To avoid the danger of a provider playing a hold-up game on
termination, customer can plan for transition by obtaining a complete copy of
the website periodically during the course of the relationship. Where feasible,
provider should deliver a complete copy very frequently (on the order of every
24 hours or less) so that a minimal amount of data would be lost if customer makes
a forced emergency transition.
On rare occasions, customers have gotten themselves into
trouble when the provider registered the website's domain name with Internic
and listed provider's employees as the administrative and technical contact
(instead of listing customer's employees). When this happens, Internic will
only respond to provider regarding changes the IP addresses of the website
servers, again permitting provider to play a hold-up game on termination.
Immediately following domain name registration, customer should check its
domain name registration to ensure that Internic will honor its request for
changes to the domain name records.
To the extent that the provider is also the website
developer, if customer does not obtain complete ownership of the website, then
customer needs to provide a license for the provider-owned components
Customers will want to restrict provider from making unauthorized modifications to the website (although, as described below, providers might demand the right to make changes to minimize their liability). If providers are given the right to make some modifications to the website, usually customer will want an opportunity to review and approve these modifications before the changes "go live."
Compliance with Laws
Particularly in the co-branding and outsourcing context, customers will want to specify that provider will comply with all applicable laws.
Conclusion about Web Hosting Agreements
At their core, hosting agreements are like any other
services agreement, and therefore all of the usual rules of commercial
contracting apply. As is the case with development agreements, the service
provider will usually benefit from the default rules and therefore will be
silent on provisions in the agreement, while the customer will have a long list
of needed provisions.
While much of this article has focused on customer's wants
and needs, web hosts should address the possibility of their liability for
customer's (or its users') content. Historically, web hosts have feared that
they would be liable for customer content. Recently, the trend has been away
from host liability for customer content, but there remain some areas of
Defamation and Other "Publisher/Speaker" Torts
47 U.S.C. §230(c)(1) says: "No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider." This section should insulate web hosts from possible liability for any publisher or speaker torts attributable to customer's content. A recent application of this section was seen in Zeran v. America Online, 129 F.3d 327 (4th Cir. 1997), which held that AOL, as the host of a message board which contained allegedly defamatory statements by a user, was not liable for any possible defamation claim based on these statements (regardless of whether or not AOL knew about the defamatory statements and failed to act reasonably in removing them).
While Zeran certainly is favorable to web hosts,
there remain a few points of ambiguity that could limit the benefits of Section
230(c)(1). First, we do not know the scope of torts deemed to be publisher or
speaker torts; while this appears to be a broad set of torts, we do not yet
know the boundaries. Second, the statute says that a "provider or user of
interactive computer services" is insulated from liability; no web host
yet has been determined to be a provider or user of an interactive computer
service for purposes of this statute, and the statutory definition was drafted
in a way that does not clearly include web hosts.
Though there are no clear cases involving web host liability for customer content that is obscene or child pornographic, web hosts may be protected by Section 230(c)(1) described above. If not, web hosts are likely to be protected at least as extensively as the bookseller was protected in Smith v. California, 361 U.S. 147 (1959), which invalidated a statute imposing strict liability for the distribution of obscenity as applied to a bookseller.
Marobie-FL, Inc. v. National Association of Fire Equipment Distributors, 1997 WL 709747 (N.D. Ill. Nov. 13, 1997) is the only case that has squarely dealt with web host liability for customer content. In Marobie, a customer infringed third party copyrighted material, and the copyright owner sued both the customer and the web host. The Marobie court found that the web host was not liable for direct infringement, because it only provided the facilities for the customer to commit copyright infringement, much like the provider of a public copying machine would.
With respect to contributory copyright infringement, it was
unclear to the court whether the web host knew that any customer content was
copyrighted and the degree to which the web host "monitored, controlled,
or had the ability to monitor or control" the customer content. Therefore,
the court could not reach a summary judgement. The Marobie court ruled
that the web host was not vicariously liable for the copyright infringement,
because the web host charged a flat fee irrespective of the volume of
customer's content, and the web host did not receive any compensation that
depended on the number of visitors to the customer content.
The Marobie holding largely tracks what most practitioners
believed was the state of web host liability for copyright infringement since Religious
Technology Center v. Netcom On-Line Communication Services, Inc., 907 F.
Supp. 1361 (N.D. Cal. 1995), which held that Netcom, as the provider of access
to Usenet postings, was not liable for direct or vicarious copyright
infringement in a Usenet posting and was liable for contributory copyright
infringement only if Netcom knew or should have known of the copyright
infringement and failed to remove it within a reasonable period of time.
Several cases have followed the Netcom reasoning, including Sega Enterprises
Ltd. v. MAPHIA, 948 F. Supp. 923 (N.D. Cal. 1996) and Sega Enterprises
Ltd. v. Sabella, 1996 U.S. Dist. LEXIS 20470 (N.D. Cal. December 18, 1996).
However, the Marobie ruling leaves open several possible bases for web host liability, including:
(i) the web host knew that customer's
content was owned by a third party and web host failed to act in a reasonable
period of time;
(ii) the web host monitored, controlled, or had the ability to monitor or control the customer content and failed to do so reasonably (note that this factor is broader than was contemplated under Netcom); or
(iii) the web host was compensated in a way that gave it a direct financial benefit from the copyright infringement.
Finally, although this line of reasoning was rejected by Marobie
and Netcom, there are a number of cases that have held system operators
directly liable for copyright infringement caused by users. See, e.g., Playboy
Enterprises, Inc. v. Frena, 839 F. Supp. 1552 (M.D. Fla. 1993); Central
Point Software, Inc. v. Nugent, 903 F. Supp. 1057 (E.D. Tex. 1995); Playboy
Enterprises, Inc. v. Webbworld, Inc., 1997 U.S. Dist. LEXIS 21264 (N.D.
Tex. December 11, 1997) (note that the Webbworld case is a bit confusing
because the system operator did more to process user content than system
operators normally perform). These cases hold significantly more peril for the
web host, because they would effectively hold the web host strictly liable for
copyright infringement in customer content.
Early cases such as the Frena case and Sega Enterprises Ltd. v. MAPHIA, 857 F. Supp. 679 (N.D. Cal. 1994) seemed to indicate that system operators might also be liable for trademark infringement caused by their users.
While these cases were not thoroughly reasoned, a more
recent case still suggests that web hosts might be liable for contributory
trademark infringement. Lockheed Martin Corp. v. Network Solutions, Inc., 985
F. Supp. 949 (C.D. Cal. 1997) involved a claim by a trademark owner against NSI
for contributory trademark infringement for registering allegedly infringing
domain names. While the court held that NSI was not contributorily liable, the
court made several statements that suggested it might have analyzed web host
liability differently. For example, the court comments that "[w]here
domain name registration is necessary, the ISP usually acts as an agent to
secure and maintain registration." This type of statement implies that the
court might hold the ISP (or, in our situation, a web host) who registers a
domain name for a customer liable for contributory trademark infringement on an
In a web hosting agreement, providers should contractually
restrict customer from providing any content that is illegal or could create
liability for provider. Provider should also try to couple this restriction
with an indemnity for any suits based on customer content. While these
provisions are both helpful, there is always a risk that provider may be liable
and the indemnity may prove insufficient. Therefore, it is also a good idea for
providers to procure insurance for these types of risks; such insurance is
becoming increasingly available.
Finally, provider should retain in its contract the ability
to take any action it deems necessary or prudent (including without limitation
removing content) if provider believes that customer's (or customer's users')
content may create liability for provider.
As repeatedly indicated, provider-favorable agreements tend
to operate largely by silence while customer-oriented agreements incorporate a
large number of substantive concerns. Empirically, this has proven true:
agreements provided by providers tend to be painfully short, and agreements
provided by customers tend to be egregious and oppressive. Perhaps this
article, by helping focus each party on reasonable compromises, will serve as a
catalyst towards reaching a more expeditious equilibrium in drafting Web
development and hosting agreements.
Eric Goldman (formerly Eric
Schlachter) is an attorney practicing cyberspace law with Cooley Godward LLP in
Palo Alto, California. He also is an adjunct professor of Cyberspace Law at
Santa Clara University School of Law. All cases cited in this article can be
found through the "Syllabus" on Mr. Goldman' personal home page,
located at http://eric_goldman.tripod.com.
Mr. Goldman can be reached at email@example.com .